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The Problem 站 县 


今天 ， 我 们 使 用 通用 的 应 用 程序 或 者 类 库 来 实现 互相 通讯 ， 比 如 ， 我 们 经 常 使 用 一 个 HTTP 
客户 端 库 来 从 Web 服务 器 上 获取 信息 ， 或 者 通过 web 服务 来 执行 一 个 远程 的 调用 。 


然而 ， 有 时 候 一 个 通用 的 协议 或 他 的 实现 并 没有 很 好 的 满足 需求 。 比 如 我 们 无 法 使 用 一 个 通 
用 的 HTTP 服务 器 来 处 理 大 文件 、 电 子 邮 件 以 及 近 实 时 消息 ， 比 如 金融 信息 和 多 人 游戏 数 
据 。 我 们 需要 一 个 高 度 优化 的 协议 来 处 理 一些 特 殊 的 场景 。 例 如 你 可 能 想 实现 一 个 优化 了 的 
Ajax 的 聊天 应 用 、 媒 体 流 传输 或 者 是 大 文件 传输 器 ， 你 甚至 可 以 自己 设计 和 实现 一 个 全 新 的 
协议 来 准确 地 实现 你 的 需求 。 


另 一 个 不 可 避免 的 情况 是 当 你 不 得 不 处 理 遗 留 的 专 有 协议 来 确保 与 昌 系 统 的 互 操作 性 。 在 这 
种 情况 下 ， 重 要 的 是 我 们 如 何 才能 快速 实现 协议 而 不 牺牲 应 用 的 稳定 性 和 性 能 。 


The Solution 解决 


Netty 是 一 个 提供 asynchronous event-driven (异步 事件 驱动 ) 的 网 络 应 用 框架 ， 是 一 个 用 
以 快速 开发 高 性 能 、 可 扩展 协议 的 服务 器 和 客户 端 。 


换 句 话说 ，Netty 是 一 个 NIO 客户 端 服 务 器 框架 ， 使 用 它 可 以 快速 简单 地 开发 网 络 应 用 程 
序 ， 比 如 服务 器 和 客户 端的 协议 。 Netty 大 大 简化 了 网 络 程序 的 开发 过 程 比如 TCP 和 UDP 的 
socket 服务 的 开发 。 


“快速 和 简单 "并 不 意味 着 应 用 程序 会 有 难 维护 和 性 能 低 的 问题 ，Netty 是 一 个 精心 设计 的 框 
架 ， 它 从 许多 协议 的 实现 中 吸收 了 很 多 的 经 验 比 如 FTP、SMTP、HTTP、 许 多 二 进 制 和 基于 
文本 的 传统 协议 .因此 ，Netty 已 经 成 功 地 找到 一 个 方式 ,在 不 失灵 活性 的 前 提 下 来 实现 开发 的 


有 一 些 用 户 可 能 已 经 发 现 其 他 的 一 些 网 络 框架 也 声称 自己 有 同样 的 优势 ， 所 以 你 可 能 会 问 是 
Netty 和 它们 的 不 同 之 处 。 答 案 就 是 Netty 的 哲学 设计 理念 。Netty 从 开始 就 为 用 户 提供 了 用 
户 体 验 最 好 的 API 以 及 实现 设计 。 正 是 因为 Netty 的 哲学 设计 理念 ， 才 让 您 得 以 轻松 地 阅读 
本 指南 并 使 用 Netty 。 


Getting Started 开始 


本 章 围 绕 Netty 的 核心 架构 ， 通 过 简单 的 示例 带 你 快速 入 门 。 当 你 读 完 本 章节 ， 你 马上 就 可 以 
用 Netty 写 出 一 个 客户 端 和 服务 器 。 

如 果 你 在 学 习 的 时 候 喜欢 "top-down ( 自 顶 向 下 ) ”， 那 你 可 能 需要 要 从 第 二 章 《Architectural 
Overview (架构 总 览 ) 》 开 始 ， 然 后 再 回 到 这 里 。 


Before Getting Started 开始 之 前 


运行 本 章 示例 之 前 ， 需 要 准备 : 最 新 版 的 Netty 以 及 JDK 1.6 或 以 上 版 本 。 最 新 版 的 Netty 
自行 下 载 JDK。 


阅读 本 章节 过 程 中 ， 你 可 能 会 对 相关 类 有 疑惑 ， 关 于 这 些 类 的 详细 的 信息 请 请 参考 AP| 说 明 
文档 。 为 了 方便 ， 所 有 文档 中 涉及 到 的 类 名 字 都 会 被 关联 到 一 个 在 线 的 API 说 明 。 当 然 ， 如 
果 有 任何 错误 信息 、 语 法 错误 或 者 你 有 任何 好 的 建议 来 改进 文档 说 明 ， 那 么 请 联系 Netty 社 
区 。 


译 者 注 : 对 本 翻译 有 任何 疑问 ， 在 https:/github.com/Wwaylau/netty-4-user-guide/issues 提 问 


Writing a Discard Server 写 个 抛 齐 服务 器 


世上 最 简单 的 协议 不 是 'Hello, World! 而 是 DISCARD( 抛 弃 服 务 )。 这 个 协议 将 会 抛弃 任何 收 到 
的 数据 ， 而 不 响应 。 


为 了 实现 DISCARD 协议 ， 你 只 需 和 忽略 所 有 收 到 的 数据 。 让 我 们 从 handler (处 理 器 ) 的 实 
现 开 始 ，handler 是 由 Netty 生成 用 来 处 理 |/O 事件 的 。 


import io.netty.buffer.ByteBuf,; 


import io.netty.channel.ChannelHandlerContext; 
import io.netty.channel.ChannelInboundHandlerAdapter; 


A 
* 处 理 服务 端 channel. 
yA 
public class DiscardServerHandler extends ChannelInboundHandlerAdapter { // (1) 


Q@override 

public void channelRead(ChannelHandlerContext ctx, Object msg) { // (2) 
// 默默 地 丢弃 收 到 的 数据 
((ByteBuf) msg).release(); // (3) 

} 


@Override 

public void exceptionCaught(ChannelHandlerContext ctx, Throwable cause) { // (4) 
// 当 出 现 异 常 就 关闭 连接 
cause.printSstackTrace(); 
ctx.close(); 


1.DiscardServerHandler 继承 自 ChannellnboundHandlerAdapter， 这 个 类 实现 了 
ChannellnboundHandler 接 口 ，ChannellnboundHandler 提供 了 许多 事件 处 理 的 接口 方法 ， 
然后 你 可 以 覆盖 这 些 方法 。 现 在 仅仅 只 需要 继承 ChannellnboundHandlerAdapter 类 而 不 是 你 
自己 去 实现 接口 方法 。 

2. 这 里 我 们 和 覆盖 了 chanelRead() 事件 处 理 方 法 。 每 当 从 客户 端 收 到 新 的 数据 时 ， 这 个 方法 会 
在 收 到 消息 时 被 调用 ， 这 个 例子 中 ， 收 到 的 消息 的 类 型 是 ByteBuf 

3. 为 了 实现 DISCARD 协议 ， 处 理 器 不 得 不 忽略 所 有 接受 到 的 消息 。ByteBuf 是 一 个 引用 计数 


对 象 ， 这 个 对 象 必 须 显示 地 调用 release() 方法 来 释放 。 请 记 住 处 理 器 的 职责 是 释放 所 有 传递 
到 处 理 器 的 引用 计数 对 象 。 通 常 ，channelRead() 方法 的 实现 就 像 下 面 的 这 段 代 码 : 


Q@override 
public void channelRead(ChannelHandlerContext ctx, Object msg) 1{ 
Cry 
// Do something with msg 
nv 
ReferenceCountUtil.release(msg); 


4.exceptionCaught() 事件 处 理 方法 是 当 出 现 ea 对 象 才 会 被 调用 ， 即 当 Netty 由 于 IO 
错误 或 者 处 理 器 在 处 理事 件 时 抛 出 的 异常 时 。 在 大 部 分 情况 下 ， 捕 获 的 异常 应 该 被 记录 下 来 

并 且 把 关联 的 CI 合 关闭 掉 。 然 而 这 个 方法 的 处 理 方式 会 在 遇 到 不 同 异常 的 情况 下 有 不 

同 的 实现 ， 比 如 你 可 能 想 在 关闭 连接 之 前 发 送 一 个 错误 码 的 响应 消息 。 


目前 为 止 一 切 都 还 不 错 ， 我 们 已 经 实现 了 DISCARD 服务 器 的 一 半 功 能 ， 剩 下 的 需要 编写 
个 main() 方法 来 启动 服务 端的 DiscardServerHandler 。 


import io.netty.bootstrap.ServerBootstrap; 


Import io.netty.channel.ChannelFuture; 

import io.netty.channel.ChannelIinitializer; 

Import io.netty.channel.ChannelOption; 

import io.netty.channel.EventLoopGroup; 

import io.netty.channel.nio.NioEventLoopGroup; 

import io.netty.channel.socket.SocketCchannel; 

import io.netty.channel.socket.nio.NioServerSocketChannel; 


VS 
* 丢弃 任何 进入 的 数据 
Wh 
public class DiscardServer { 


private int port 


public DiscardServer(int port) { 
this.port = port; 


public void run() throws Exception { 
EventLoopGroup bossGroup = new NioEventLoopGroup(); // (1) 
EventLoopGroup workerGroup = new NioEventLoopGroup(); 
try { 
ServerBootstrap b = new ServerBootstrap(); // (2) 
b.group(bossGroup, workerGroup) 
.Cchannel(NioServerSocketCchannel.class) // (3) 
.childHandler (new ChannelInitializer<SocketCchannel>() { // (4) 
Q@override 
public void initChannel(SocketChannel ch) throws Exception { 
ch.pipeline().addLast(new DiscardServerHandler()); 


} 
}) 
.Option(Channeloption.SO_ BACKLOG, 128) 2) 
.Childoption(Channe1loption.SO_KEEPALIVE，true); // (6) 


// 绑 定 端口 ， 开 始 接收 进来 的 连接 
ChannelFuture f = b.bind(port).sync(); // (7) 


// 等 待 服务 器 ” socket 关闭 。 
// 在 这 个 例子 中 ， 这 不 会 发 生 ， 但 你 可 以 优雅 地 关闭 你 的 服务 器 。 
f.channel().closeFuture().sync(); 

} finally { 
workerGroup.shutdownGracefully(); 
bossGroup.shutdownGracefully(); 


} 


public static void main(String[] args) throws Exception { 
int port; 
if (args.length > 0) { 
port = Integer.parseInt(args[0]); 
} else { 
port = 8080; 
} 


new DiscardServer(port).run(); 


1.NioEventLoopGroup 是 用 来 处 理 |/O 操 作 的 多 线程 事件 循环 器 ，Netty 提供 了 许多 不 同 的 
EventLoopGroup 的 实现 用 来 处 理 不 同 的 传输 。 在 这 个 例子 中 我 们 实现 了 一 个 服务 端的 应 用 ， 
因此 会 有 2 个 NioEventLoopGroup 会 被 使 用 。 第 一 个 经 常 被 叫做 'boss'， 用 来 接收 进来 的 连 
接 。 第 二 个 经 常 被 叫做 "worker， 用 来 处 理 已 经 被 接收 的 连接 ， 一 旦 boss' 接 收 到 连接 ， 就 会 
把 连接 信息 注册 到 'Worker 上 “。 如 何 知道 多 少 个 线程 已 经 被 使 用 ， 如 何 映射 到 已 经 创建 的 
Channel 上 都 需要 依赖 于 EventLoopGroup 的 实现 ， 并 且 可 以 通过 构造 函数 来 配置 他 们 的 关 


2. AL 是 一 个 启动 NIO 服务 的 辅助 启动 类 。 你 可 以 在 这 个 服务 中 直接 使 用 
Channel， 但 是 这 会 是 一 个 复杂 的 处 理 过 程 ， 在 很 多 情况 下 你 并 不 需要 这 样 做 。 


3. 这 里 我 们 指定 使 用 NioServerSocketChannel 类 来 举例 说 明 一 个 新 的 Channel 如 何 接 收 进 来 
的 连接 。 


4. 这 里 的 事件 处 理 类 经 常会 被 用 来 处 理 一 个 最 近 的 已 经 接收 的 Channel。Channellnitializer 是 
一 个 特殊 的 处 理 类 ， 他 的 目的 是 帮助 使 用 者 配置 一 个 新 的 Channel。 也 许 你 想 通 过 增加 一 些 
处 理 类 比如 DiscardServerHandler 来 配置 一 个 新 的 Channel 或 者 其 对 应 的 ChannelPipeline 
来 实现 你 的 网 络 程序 。 当 你 的 程序 变 的 复杂 时 ， 可 能 你 会 增加 更 多 的 处 理 类 到 pipline 上 ， 然 
后 提取 这 些 匿名 类 到 最 顶层 的 类 上 。 


5. 你 可 以 设置 这 里 指定 的 Channel 实现 的 配置 参数 。 我 们 正在 写 一 个 TCP/IP 的 服务 端 ， 因 此 
我 们 被 允许 设置 socket 的 参数 选项 比如 tcpNoDelay 和 keepAlive。 请 参考 ChannelOption 和 
详细 的 ChannelConfig 实现 的 接口 文档 以 此 可 以 对 ChannelOption 的 有 一 个 大 概 的 认识 。 


6. 你 关注 过 option() 和 childOption() 吗 ? option() 是 提供 给 NioServerSocketChannel| 用 来 接 
收 进来 的 连接 。childOption() 是 提供 给 由 父 管 道 ServerChannel 接收 到 的 连接 ， 在 这 个 例子 
中 也 是 NioServerSocketChannel 。 


7. 我 们 继续 ， 剩 下 的 就 是 绑 定 端口 然后 启动 服务 。 这 里 我 们 在 机 器 上 绑 定 了 机 器 所 有 网 卡 上 的 
8080 端口 。 当 然 现 在 你 可 以 多 次 调用 bind() 方法 (基于 不 同 绑 定 地 址 ) 。 


恭喜 ! 你 已 经 熟练 地 完成 了 第 一 个 基于 Netty 的 服务 端 程序 。 


Looking into the Received Data 查看 收 到 的 
数据 


现在 我 们 已 经 编写 出 我 们 第 一 个 服务 端 ， 我 们 需要 测试 一 下 他 是 否 丨 的 可 以 运行 。 最 简单 的 
测试 方法 是 用 telnet 命令 。 例 如 ， 你 可 以 在 命令 行 上 输入 telnet localhost 8089 或 者 其 他 类 
型 参数 。 


然而 我 们 能 说 这 个 服务 端 是 正常 运行 了 吗 ? 事实 上 我 们 也 不 知道 ， 因 为 他 是 一 个 discard 服 
务 ， 你 根本 不 可 能 得 到 任何 的 响应 。 为 了 证 明 他 仍然 是 在 正常 工作 的 ， 让 我 们 修改 服务 端的 
程序 来 打印 出 他 到 底 接 收 到 了 什么 


我 们 已 经 知道 channelRead() 方法 是 在 数据 被 接收 的 时 候 调 用 。 让 我 们 放 一 些 代码 到 
DiscardServerHandler 类 的 channelRead() 方法 。 


Q@Override 
public void channelRead(ChannelHandlerContext ctx, Object msg) { 
ByteBuf in = (ByteBuf) msg; 
try { 
while (in.isReadable()) { // (1) 
System.out.print((char) in.readByte()); 
System.out.flush(); 


} 
} finally { 
ReferenceCountUtil.release(msg); // (2) 


} 


1. 这 个 低 效 的 循环 事实 上 可 以 简化 
为 :System.out.println(in.toStringlio.netty.util.CharsetUtil.US_ASCID) 


2. 或 者 ， 你 可 以 在 这 里 调用 in.release()。 


如 果 你 再 次 运行 telnet 命令 ， 你 将 会 看 到 服务 端 打印 出 了 他 所 接收 到 的 消息 。 


完整 的 discard server 代 码 放 在 了 io.netty.example.discard 包 下 面 。 


译 者 注 : 翻译 版 本 的 项 目 源码 见 https:/github.com/waylau/netty-4-user-guide-demos 中 


的 com.waylau.netty.demo.discard 包 下 
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Writing an Echo Server 写 个 应 答 服 务 跨 


到 目前 为 止 ， 我 们 虽然 接收 到 了 数据 ， 但 没有 做 任何 的 响应 。 然 而 一 个 服务 端 通常 会 对 一 个 
请 求 作 出 响应 。 让 我 们 学 习 怎 样 在 ECHO 协议 的 实现 下 编写 一 个 响应 消息 给 客户 端 ， 这 个 协 
议 针 对 任何 接收 的 数据 都 会 返回 一 个 响应 。 


和 discard server 唯一 不 同 的 是 把 在 此 之 前 我 们 实现 的 channelRead() 方法 ， 返 回 所 有 的 数 
据 替 代打 印 接收 数据 到 控制 台 上 的 逻辑 。 因 此 ， 需 要 把 channelRead() 方法 修改 如 下 : 


Q@override 

public void channelRead(ChannelHandlerContext ctx, Object msg) { 
ctx.write(msg); // (1) 
ctx.flush(); // (2) 


1. ChannelHandlerContext 对 象 提供 了 许多 操作 ， 使 你 能 够 触发 各 种 各 样 的 MO 事件 和 操 
作 。 这 里 我 们 调用 了 write(Object) 方法 来 逐 字 地 把 接受 到 的 消息 写 入 。 请 注意 不 同 于 
DISCARD 的 例子 我 们 并 没有 释放 接受 到 的 消息 ， 这 是 因为 当 写 入 的 时 候 Netty 已 经 帮 有 我 
们 释放 了 。 

2.，ctx.write(Object) 方法 不 会 使 消息 写 入 到 通道 上 ， 他 被 缓冲 在 了 内 部 ， 你 需要 调用 
ctx.flush() 方法 来 把 缓冲 区 中 数据 强行 输出 。 或 者 你 可 以 用 更 简洁 的 
cxt.writeAndFlush(msg) 以 达到 同样 的 目的 。 


如 果 你 再 一 次 运行 telnet 命令 ， 你 会 看 到 服务 端 会 发 回 一 个 你 已 经 发 送 的 消息 。 
完整 的 echo 服 务 的 代码 放 在 了 io.netty.example.echo 包 下 面 。 


译 者 注 : 翻译 版 本 的 项 目 源 码 见 https:/github.com/waylau/netty-4-user-guide-demos 中 
的 com.waylau.netty.demo.echo 包 下 


Writing a Time Server 写 个 时 间 服 务 器 


在 这 个 部 分 被 实现 的 协议 是 TIME 协议。 和 之 前 的 例子 不 同 的 是 在 不 接受 任何 请 求 时 他 会 发 
站 息 ， 并 且 一 旦 消息 发 送 就 会 立即 关闭 连接 。 在 这 个 例子 中 ， 你 会 学 
习 到 如 何 构建 和 发 送 一 个 消息 ， 然 后 在 完成 时 关闭 连接 。 


因为 我 们 将 会 忽略 任何 接收 到 的 数据 ， 而 只 是 在 连接 被 创建 发 送 一 个 消息 ， 所 以 这 次 我 们 不 
能 使 用 channelRead() 方法 了 ， 代 替 他 的 是 ， 我 们 需要 履 盖 channelActive() 方法 ， 下 面 的 就 
是 实现 的 内 容 : 


public class TimeServerHandler extends ChannelInboundHandlerAdapter { 


Q@Override 
public void channelActive(final ChannelHandlerContext ctx) { // (1) 
final ByteBuf time = ctx.alloc().buffer(4); // (2) 
time.writeInt((int) (System.currentTimeMillis() / 1000L + 2208988800L ) ) ; 


final ChannelFuture f = ctx.writeAndFlush(time); // (3) 
f.addListener(new ChannelFutureListener() { 
@Override 
public void operationComplete(ChannelFuture future) { 
assert f == future; 
ctx.close( ); 


} 
}); // (4) 
} 
Q@Override 


public void exceptionCaught(ChannelHandlerContext ctx, Throwable cause) { 
cause.printSstackTrace(); 
ctx.close(); 


1.channelActive() 方法 将 会 在 连接 被 建立 并 且 准 备 进行 通信 时 被 调用 。 因 此 让 我 们 在 这 个 方 
法 里 完成 一 个 代表 当前 时 间 的 32 位 整数 消息 的 构建 工作 。 


2. 为 了 发 送 一 个 新 的 消息 ， 我 们 需要 分 配 一 个 包含 这 个 消息 的 新 的 缓冲 。 因 为 我 们 需要 写 入 一 
个 32 位 的 整数 ， 因 此 我 们 需要 一 个 至 少 有 4 个 字 节 的 ByteBuf。 通 过 
ChannelHandlerContext.alloc() 得 到 一 个 当前 的 ByteBufAllocator， 然 后 分 配 一 个 新 的 缓冲 。 


3. 和 往常 一 样 我 们 需要 编写 一 个 构建 好 的 消息 。 但 是 ， flip 在 哪 ? 难道 我 们 使 用 NIO 发 
送 消息 时 不 是 调用 java.nio.ByteBuffer.flip() 吗 ? ot 以 没有 这 个 方法 因为 有 两 个 指 
针 ， 一 个 对 应 读 操作 一 个 对 应 写 操作 。 当 你 向 ByteBuf 里 写 入 数据 的 时 候 写 指针 的 索引 就 会 


增加 ， 同 时 读 指针 的 索引 没有 变化 。 读 指针 索引 和 写 指针 索引 分 别 代表 了 消息 的 开始 和 结 

束 。 

比较 起 来 ，NIO 缓冲 并 没有 提供 一 种 简洁 的 方式 来 计算 出 消息 内 容 的 开始 和 结尾 ， 除 非 你 调 
用 flip 方法 。 当 你 忘记 调用 flip 方法 而 引起 没有 数据 或 者 错误 数据 被 发 送 时 ， 你 会 陷入 困境 。 
这 样 的 一 个 错误 不 会 发 生 在 Netty 上 ， 因 为 我 们 对 于 不 同 的 操作 类 型 有 不 同 的 指针 。 你 会 发 现 
这 样 的 使 用 方法 会 让 你 过 程 变 得 更 加 的 容 萄 ， 因 为 你 已 经 习惯 一 种 没有 使 用 flip 的 方式 。 


另外 一 个 点 需要 注意 的 是 ChannelHandlerContext.write() (和 writeAndFlush() ) 方 法 会 返回 一 
个 ChannelFuture 对 象 ， 一 个 ChannelFuture 代表 了 一 个 还 没有 发 生 的 |/O 操作 。 这 意味 着 
任何 一 个 请 求 操作 都 不 会 马上 被 执行 ， 因 为 在 Netty 里 所 有 的 操作 都 是 异步 的 。 举 个 例子 下 面 
的 代码 中 在 消息 被 发 送 之 前 可 能 会 先 关闭 连接 。 


Channel ch = 
ch.writeAndFlush(message); 
ch.close( ); 


因此 你 需要 在 Write() 方法 返回 的 ChannelFuture 完成 后 调用 close() 方法 ， 然 后 当 他 的 写 操 
作 已 经 完成 他 会 通知 他 的 监听 者 。 请 注意 ,close() 方法 也 可 能 不 会 立马 关闭 ， 他 也 会 返回 一 个 
ChannelFuture 。 


4. 当 一 个 号 请 求 已 经 完成 是 如 何 通知 到 我 们 ? 这 个 只 需要 简单 地 在 返回 的 ChannelFuture 上 
增加 一 个 ChannelFutureListener。 这 里 我 们 构建 了 一 个 匿名 的 ChannelFutureListener 类 用 来 
在 操作 完成 时 关闭 Channel。 


或 者 ， 你 可 以 使 用 简单 的 预定 义 监听 器 代码 : 


f.addListener(ChanneJIFutureListener .CLOSE) ， 


为 了 测试 我 们 的 time 服 务 如 我 们 期 望 的 一 样 工 作 ， 你 可 以 使 用 UNIX 的 rdate 命令 


$ rdate -0 <port> -p <host> 


Port 是 你 在 main() 有 函数 中 指定 的 端口 ，host 使 用 localhost 就 可 以 了 。 


Writing a Time Client 写 个 时 间 究 


不 像 DISCARD 和 ECHO 的 服务 端 ， 对 于 TIME 协议 我 们 需要 一 个 客户 端 ,因为 人 们 不 能 把 一 
个 32 位 的 二 进 制 数据 翻译 成 一 个 日 期 或 者 日 历 o 在 这 一 部 分 9 我 们 将 会 讨论 如 何 确保 服务 端 
是 正常 工作 的 ， 并 且 学 习 怎 样 用 Netty 编写 一 个 客户 端 。 


在 Netty 中 ,编写 服务 端 和 客户 端 最 大 的 并 且 唯 一 不 同 的 使 用 了 不 同 的 BootStrap 和 Channel 的 
实现 。 请 看 一 下 下 面 的 代码 : 


public class TimeClient { 
public static void main(String[] args) throws Exception { 


String host = args[0]; 
int port = Integer.parseIint(args[1]); 
EventLoopGroup workerGroup = new NioEventLoopGroup(); 


try { 
Bootstrap b = new Bootstrap(); // (1) 
b.group(workerGroup); // (2) 
b.channel(NioSocketChannel.class); // (3) 
b.option(ChannelOption.SO_ KEEPALIVE, true); // (4) 
b.handler(new ChannelInitializer<SocketChannel>() { 
@Override 
public void initCchannel(SocketChannel ch) throws Exception { 
ch.pipeline().addLast(new TimeClientHandler()); 
} 
}); 


/ 启动 客户 端 
ChannelFuture f = b.connect(host, port).sync(); // (5) 


AS 


// 等 待 连接 关闭 

f.,channel().closeFuture().sync(); 
} finally { 

workerGroup.shutdownGracefully(); 


} 


1. ti 和 ServerBootstrap 类 似 , 不 过 他 是 对 非 服务 端的 channel 而 言 ， 比 如 客户 端 或 者 
连接 传输 模式 的 channel。 


2. 如 果 你 只 指定 了 一 个 EventLoopGroup， 那 他 就 会 即 作为 一 个 boss group ， 也 会 作为 一 个 
workder group， 尽 管 客 户 端 不 需要 使 用 到 boss worker 。 


3. 代 替 NioServerSocketChannel 的 是 NioSocketChannel, 这 个 类 在 客户 端 channel 被 创建 时 使 
用 。 


4. 不 像 在 使 用 ServerBootstrap 时 需要 用 childOption() 方法 ， 因 为 客户 端的 SocketChannel 


5. 我 们 用 connect() 方法 代替 了 bind() 方法 。 


正如 你 看 到 的 ， 他 和 服务 端的 代码 是 不 一 样 的 。ChannelHandler 是 如 何 实现 的 ?他 应 该 从 服 
务 端 接受 一 个 32 位 的 整数 消息 ， 把 他 翻译 成 人 们 能 读 懂 的 格式 ， 并 打印 翻译 好 的 时 间 ， 最 后 
关闭 连接 : 


import java.util.Date; 


public class TimeClientHandler extends ChannelInboundHandlerAdapter { 
Q@Override 
public void channelRead(ChannelHandlerContext ctx, Object msg) { 
ByteBuf m = (ByteBuf) msg; // (1) 
try { 
long currentTimeMillis = (m.readUnsignedInt() - 2208988800L) * 1000L; 
System.out.println(new Date(currentTimeMil]lis)); 
ctx.close( ); 
} finally { 
m.release(); 
} 
} 


@Override 

public void exceptionCaught(ChannelHandlerContext ctx, Throwable cause) { 
cause.printSstackTrace(); 
ctx.close(); 


1. 在 TCP/IP 中 ，Netty 会 把 读 到 的 数据 放 到 ByteBuf 的 数据 结构 中 。 


这 样 看 起 来 非常 简单 ， 并 且 和 服务 端的 那个 例子 的 代码 也 相差 不 多 。 然 而 ， 处 理 器 有 时 候 会 
因为 抛 出 IndexOutOfBoundsException 而 拒绝 工作 。 在 下 个 部 分 我 们 会 讨论 为 什么 会 发 生 这 
种 情况 。 


Dealing with a Stream-based Transport 处 
理 一 个 基于 流 的 传输 


One Small Caveat of Socket Buffer 关于 Socket 
Buffer 的 一 个 小 警告 


基于 流 的 传输 比如 TCPIIP, 接收 到 数据 是 存在 socket 接收 的 buffer 中 。 不 幸 的 是 ， 基 于 流 的 
传输 并 不 是 一 个 数据 包 队 列 ， 而 是 一 个 字 节 队 列 。 意 味 着 ， 即 使 你 发 送 了 2 个 独立 的 数据 包 
操作 系统 也 不 会 作为 2 个 消息 处 理 而 仅仅 是 作为 一 连 串 的 字 节 而 言 。 因 此 这 是 不 能 保证 你 远程 
写 入 的 数据 就 会 准确 地 读 取 。 举 个 例子 ， 让 我 们 假设 操作 系统 的 TCP/TP 协议 栈 已 经 接收 了 3 
个 数据 包 


et a Da sole i ， 在 你 的 应 用 程序 里 读 取 数 据 的 时 候 会 有 很 高 的 可 
EB 性 被 分 成 下 面 的 片段 


因此 ， 一 个 接收 方 不 管 他 是 客户 端 还 是 服务 端 ， 都 应 该 把 接收 到 的 数据 整理 成 一 个 或 者 多 个 
更 有 意思 并 且 能 够 让 程序 的 业务 逻辑 更 好 理解 的 数据 。 在 上 面 的 例子 中 ， 接 收 到 的 数据 应 该 
被 构造 成 下 面 的 格式 : 


The First Solution 办 法 一 


回 到 TIME 客户 端 例子 。 同 样 也 有 类 似 的 问题 。 一 个 32 位 整 型 是 
会 被 经 常 拆 分 到 到 不 同 的 数据 段 内 。 然 而 ， 问 题 是 他 确实 可 能 会 入 
并 且 拆 分 的 可 能 性 会 随 着 通信 量 的 增加 而 增加 。 


非 的 数据 ， 他 并 不 见得 


常 小 
波 拆 分 到 不 同 的 数据 段 内 ， 


最 简单 的 方案 是 构造 一 个 内 部 的 可 积累 的 缓冲 ， 直 到 4 个 字 节 全 部 接收 到 了 内 部 缓冲 。 下 面 的 
代码 修改 了 TimeClientHandler 的 实现 类 修复 了 这 个 问题 


public class TimeClientHandler extends ChannelInboundHandlerAdapter { 
private ByteBuf buf; 


Q@override 
public void handlerAdded(ChannelHandlerContext ctx) { 
buf = ctx.alloc().buffer(4); // (1) 


Q@Override 

public void handlerRemoved(ChannelHandlerContext ctx) { 
buf.release(); // (1) 
buf = null; 


Q@override 

public void channelRead(ChannelHandlerContext ctx, Object msg) { 
ByteBuf m = (ByteBuf) msg; 
buf .writeBytes(m); // (2) 
m.release(); 


if (buf.readableBytes() >= 4) { // (3) 
long currentTimeMillis = (buf.readUnsignedIint() - 2208988800L) * 1000L; 
System.out.println(new Date(currentTimeMil]lis)); 
ctx.close(); 


@Override 

public void exceptionCaught(ChannelHandlerContext ctx, Throwable cause) { 
cause.printSstackTrace(); 
ctx.close(); 


1.ChannelHandler 有 2 个 生命 周期 的 监听 方法 : handlerAdded() 和 handlerRemoved()。 你 可 
以 完成 任意 初始 化 任务 只 要 他 不 会 被 阻塞 很 长 的 时 间 。 


2. 首 先 ， 所 有 接收 的 数据 都 应 该 被 累积 在 buf 变量 里 。 


3. 然 后 ， 处 理 器 必须 检查 buf 变量 是 否 有 足够 的 数据 ， 在 这 个 例子 中 是 4 个 字 节 ， 然 后 处 理 实 
际 的 业务 逻辑 。 否 则 ，Netty 会 重复 调用 channelRead() 当 有 更 多 数据 到 达 直 到 4 个 字 节 的 数 
据 被 积累 。 


The Second Solution 方法 二 


尽管 第 一 个 解决 方案 已 经 解决 了 TIME 客户 端的 问题 了 ， 但 是 修改 后 的 处 理 器 看 起 来 不 那么 
的 简洁 ， 想 象 一 下 如 果 由 多 个 字段 比如 可 变 长 度 的 字段 组 成 的 更 为 复杂 的 协议 时 ， 你 的 
ChannellnboundHandler 的 实现 将 很 快 地 变 得 难以 维护 。 


正如 你 所 知 的 ， 你 可 以 增加 多 个 ChannelHandler 到 ChannelPipeline ,因此 你 可 以 把 一 整个 
ChannelHandler 拆 分 成 多 个 模块 以 减少 应 用 的 复杂 程度 ， 比 如 你 可 以 把 TimeClientHandler 
拆 分 成 2 个 处 理 器 : 


e TimeDecoder 处 理 数 据 拆 分 的 问题 
e TimeClientHandler 原始 版 本 的 实现 


幸运 地 是 ，Netty 提供 了 一 个 可 扩展 的 类 ， 帮 你 完成 TmeDecoder 的 开发 。 


public class TimeDecoder extends ByteToMessageDecoder { // (1) 
Q@Override 
protected void decode(ChannelHandlerContext ctx, ByteBuf in, List<Object> out) {/ 
ZTC 
if (in.readableBytes() < 4) { 
return; // (3) 
} 


out.add(in.readBytes(4)); // (4) 


1.ByteToMessageDecoder 是 ChannellnboundHandler 的 一 个 实现 类 ， 他 可 以 在 处 理 数据 拆 
分 的 问题 上 变 得 很 简单 。 


2. 每 当 有 新 数据 接收 的 时 候 ，ByteToMessageDecoder 都 会 调用 decode() 方法 来 处 理 内 部 的 
那个 累积 缓冲 。 


3.Decode() 方法 可 以 决定 当 累 积 缓冲 里 没有 足够 数据 时 可 以 往 out 对 象 里 放任 意 数据 。 当 有 
更 多 的 数据 被 接收 了 ByteToMessageDecoder 会 再 一 次 调用 decode() 方法 。 


4. 如 果 在 decode() 方法 里 增加 了 一 个 对 象 到 out 对 象 里 ， 这 意味 着 解码 器 解码 消息 成 功 。 
ByteToMessageDecoder 将 会 丢弃 在 累积 缓冲 里 已 经 被 读 过 的 数据 。 请 记得 你 不 需要 对 多 条 
消息 调用 decode()，ByteToMessageDecoder 会 持续 调用 decode() 直到 不 放任 何 数据 到 out 
里 。 


现在 我 们 有 另 外 一 个 处 理 器 插入 到 ChannelPipeline 里 ， 我 们 应 该 在 TimeClient 里 修改 
Channellnitializer 的 实现 : 


b.handler(new ChannelInitializer<SocketChannel>() { 
@Override 
public void initChannel(SocketChannel ch) throws Exception { 
ch.pipeline().addLast(new TimeDecoder(), new TimeClientHandler()); 


}); 


如 果 你 是 一 个 大 胆 的 人 ， 你 可 能 会 尝试 使 用 更 简单 的 解码 类 ReplayingDecoder。 不 过 你 还 是 
需要 参考 一 下 API 文档 来 获取 更 多 的 信息 。 


public class TimeDecoder extends ReplayingDecoder<Void> { 
Q@Override 
protected void decode( 
ChannelHandlerContext ctx, ByteBuf in, List<Object> out) { 
out.add(in.readBytes(4)); 


此 外 ，Netty 还 提供 了 更 多 开 箱 即 用 的 解码 器 使 你 可 以 更 简单 地 实现 更 多 的 协议 ， 帮 助 你 避免 
开发 一 个 难以 维护 的 处 理 器 实现 。 请 参考 下 面 的 包 以 获取 更 多 更 详细 的 例子 : 


e。 对 于 二 进 制 协议 请 看 io.netty.example.factorial 
e 对 于 基于 文本 协议 请 看 io.netty.example.telnet 


译 者 注 : 翻译 版 本 的 项 目 源 码 见 https:/github.com/Wwaylau/netty-4-user-guide-demos 中 


的 com.waylau.netty.demo.factorial 和 com.waylau.netty.demo. telnet 包 下 


Speaking in POJO instead of ByteBuf 用 
POJO 人 代替 ByteBuf 


我 们 回顾 了 迄今 为 止 的 所 有 例子 使 用 ByteBuf 作为 协议 消息 的 主要 数据 结构 。 在 本 节 中 ,我 们 
将 改善 的 TIME 协议 客户 端 和 服务 器 例子 ， 使 用 POJO 代替 ByteBuf 。 


在 ChannelHandler 使 用 POIO 的 好 处 很 明显 : 通过 从 ChannelHandler 中 提取 出 ByteBuf 的 
代码 ， 将 会 使 ChannelHandler 的 实现 变 得 更 加 可 维护 和 可 重用 。 在 TIME 客户 端 和 服务 器 的 
例子 中 ， 我 们 读 取 的 仅仅 是 一 个 32 位 的 整形 数据 ， 直 接 使 用 ByteBuf 不 会 是 一 个 主要 的 问 
题 。 然 而 ， 你 会 发 现 当 你 需要 实现 一 个 丨 实 的 协议 ， 分 离 代码 变 得 非常 的 必要 。 


首先 ， 让 我 们 定义 一 个 新 的 类 型 叫做 UnixTime。 


public class UnixTime { 
private final long value; 


public UnixTime() { 
this(System.currentTimeMillis() / 1000L + 2208988800L); 
} 


public UnixTime(long value) { 
this.value = value; 


} 


public long value() { 
return value; 


} 


@Override 
public String toString() { 

return new Date((value() - 2208988800L) * 1000L).toSstring(); 
} 


现在 我 们 可 以 修改 下 TimeDecoder 类 ， 返 回 一 个 UnixTime， 以 替代 ByteBuf 


Q@Override 
protected void decode(ChannelHandlerContext ctx, ByteBuf in, List<Object> out) { 


if (in.readableBytes() < 4) { 
return; 


out.add(new UnixTime(in.readUnsignedInt())); 


下 面 是 修改 后 的 解码 器 ，TimeClientHandler 不 再 任何 的 ByteBuf 代码 了 。 


Q@override 

public void channelRead(ChannelHandlerContext ctx, Object msg) { 
UnixTime m = (UnixTime) msg; 
System.out.println(m); 
ctx.close(); 


是 不 是 变 得 更 加 简单 和 优雅 了 ? 相同 的 技术 可 以 被 运用 到 服务 端 ? 让 我 们 修改 一 下 
TimeServerHandler 的 代码 。 


Q@override 

public void channelActive(ChannelHandlerContext ctx) { 
ChannelFuture f = ctx.writeAndFlush(new UnixTime()); 
f.addListener(ChannelFutureListener .CLOSE); 


现在 ,唯一 缺少 的 功能 是 一 个 编码 器 ,是 ChannelOutboundHandler 的 实现 ， 用 来 将 UnixTime 对 
象 重新 转化 为 一 个 ByteBuf。 这 是 比 编写 一 个 解码 器 简单 得 多 ,因为 没有 需要 处 理 的 数据 包 编 
码 消 息 时 拆 分 和 组 装 。 


public class TimeEncoder extends ChannelOutboundHandlerAdapter { 


Q@Override 
public void write(ChannelHandlerContext ctx, Object msg, ChannelPromise promise) { 
UnixTime m = (UnixTime) msg; 
ByteBuf encoded = ctx.alloc().buffer(4); 
encoded.writeInt((int)m.value()); 
ctx.write(encoded, promise); // (1) 


1. 在 这 几 行 代码 里 还 有 几 个 重要 的 事情 。 第 一 ， 通 过 ChannelPromise ， 当 编码 后 的 数据 被 写 
到 了 通道 上 Netty 可 以 通过 这 个 对 象 标记 是 成 功 还 是 失败 。 第 二 ， 我 们 不 需要 调用 
cxt.flush()。 因 为 处 理 器 已 经 单独 分 离 出 了 一 个 方法 void flush(ChannelHandlerContext cxt)， 
如 果 像 自己 实现 flush() 方法 内 容 可 以 自行 覆盖 这 个 方法 。 


进一步 简化 操作 ， 你 可 以 使 用 MessageToByteEncode: 


public class TimeEncoder extends MessageToByteEncoder<UnixTime> { 
Q@Override 
protected void encode(ChannelHandlerContext ctx, UnixTime msg, ByteBuf out) { 
out .writeInt((int)msg.value()); 


最 后 的 任务 就 是 在 TimeServerHandler 之 前 把 TimeEncoder 插入 到 ChannelPipeline。 但 这 
是 不 那么 重要 的 工作 。 


Shutting Down Your Application 关闭 你 的 
关闭 一 个 Netty 应 用 往往 只 需要 简单 地 通过 shutdownGracefully() 方法 来 关闭 你 构建 的 所 有 的 


EventLoopGroup。 当 EventLoopGroup 被 完全 地 终止 ,并 且 对 应 的 所 有 channel 都 已 经 被 关闭 
时 ，Netty 会 返回 一 个 Future 对 象 来 通知 你 。 


Summary 总 结 


在 这 一 章节 中 ， 我 们 快速 地 回顾 下 如 果 在 熟练 掌握 Netty 的 情况 下 编写 出 一 个 健壮 能 运行 的 网 
络 应 用 程序 。 在 Netty 接 下 去 的 章节 中 还 会 有 更 多 更 相信 的 信息 。 我 们 也 鼓励 你 去 重新 复习 下 
在 io.netty.example 包 下 的 例子 。 请 注意 社区 一 直 在 等 待 你 的 问题 和 想法 以 帮助 Netty 的 持续 
改进 ，Netty 的 文档 也 是 基于 你 们 的 快速 反馈 上 


译 者 注 : 翻译 版 本 的 项 目 源码 见 https:/github.com/waylau/netty-4-user-guide- ms 。 如 对 
本 翻译 有 任何 建议 ， 可 以 在 https://github.com/waylau/netty-4-user-guide/issues 留 言 
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Architectural Overview 架构 总 览 


在 本 章 中 ， 我 们 将 研究 Netty 提供 的 核心 功能 以 及 他 们 是 如 何 构 成 一 个 完整 的 网 络 应 用 开发 堆 
栈 顶 部 的 核心 。 你 阅读 本 章 时 ， 请 把 这 个 图 记 住 。 


Rich Buffer Data Structure 丰富 的 缓冲 实现 


Netty 使 用 自 建 的 buffer API， 而 不 是 使 用 NIO 的 ByteBuffer 来 表示 一 个 连续 的 字 节 序 列 。 与 
ByteBuffer 相 比 这 种 方式 拥有 明显 的 优势 。Netty 使 用 新 的 buffer 类 型 ByteBuf， 被 设计 为 一 
个 可 从 底层 解决 ByteBuffer 问题 ， 并 可 满足 日 常 网 络 应 用 开发 需要 的 缓冲 类 型 。 这 些 很 酷 的 

特性 包括 : 


e。 如 果 需 要 ， 人 允许 使 用 自 定 义 的 缓冲 类 型 。 

。 复合 缓冲 类 型 中 内 置 的 透明 的 零 捞 贝 实现 。 

。 开 箱 即 用 的 动态 缓冲 类 型 ， 具 有 像 StringBuffer 一 样 的 动态 缓冲 能 力 。 
。 不 再 需要 调用 的 fjp() 方 法 。 

。 正常 情况 下 具有 比 ByteBuffer 更 快 的 响应 速度 。 


更 多 信息 请 参考 : io.netty.buffer 包 描 述 
Extensibility 可 扩展 性 


ByteBuf 具有 丰富 的 操作 集 , 可 以 快速 的 实现 协议 的 优化 。 例 如 ，ByteBuf 提供 各 种 操作 用 于 访 
问 无 符号 值 和 字符 串 ， 以 及 在 缓冲 区 搜索 一 定 的 字 节 序列 。 你 也 可 以 扩展 或 包装 现 有 的 缓冲 


类 型 用 来 提供 方便 的 访问 。 自 定义 缓冲 仍然 实现 自 ByteBuf 接口 ， 而 不 是 引入 一 个 不 兼容 的 


Transparent Zero Copy 透明 的 零 拷贝 


举 一 个 网 络 应 用 到 极致 的 表现 ， 你 需要 减少 内 存 找 贝 操 作 次 数 。 你 可 能 有 一 组 缓冲 区 可 以 被 
组 合 以 形成 一 个 完整 的 消息 。 网 络 提 供 了 一 种 复合 缓冲 ， 允 许 你 从 现 有 的 任意 数 的 缓冲 区 创 
建 一 个 新 的 缓冲 区 而 无 需 内 存 找 贝 。 例 如 ， 一 个 信息 可 以 由 两 部 分 组 成 ; header 和 body。 在 
一 个 模块 化 的 应 用 ， 当 消息 发 送出 去 时 ， 这 两 部 分 可 以 由 不 同 的 模块 生产 和 装配 。 


| header | body | 
0 汪汪 十 


如 果 你 使 用 的 是 ByteBuffer ， 你 必须 要 创建 一 个 新 的 大 缓存 区 用 来 描 贝 这 两 部 分 到 这 个 新 缓 
存 区 中 。 或 者 ， 你 可 以 在 NiO 做 一 个 收集 写 操作 ， 但 限制 你 将 复合 缓冲 类 型 作为 ByteBuffer 
的 数组 而 不 是 一 个 单一 的 缓冲 区 ， 打 破 了 抽象 ， 并 且 引 入 了 复杂 的 状态 管理 。 此 外 ， 如 果 你 
不 从 NIO channel 读 或 写 ， 它 是 没有 用 的 。 


// 复合 类 型 与 组 件 类 型 不 兼容 。 
ByteBuffer[] message = new ByteBuffer[] { header, body }; 


通过 对 比 ，ByteBuf 不 会 有 敬告 ， 因 为 它 是 完全 可 扩展 并 有 一 个 内 置 的 复合 缓冲 区 。 


// 复合 类 型 与 组 件 类 型 是 兼容 的 。 
ByteBuf message = Unpooled.wrappedBuffer(header, body); 


// 因此 ， 你 甚至 可 以 通过 混合 复合 类 型 与 普通 缓冲 区 来 创建 一 个 复合 类 型 。 
ByteBuf messageWithFooter = Unpooled.wrappedBuffer(message, footer); 


// 由 于 复合 类 型 仍 是 ByteBuf， 访 问 其 内 容 很 容易 ， 
// 并 且 访 问 方法 的 行为 就 像 是 访问 一 个 单独 的 缓冲 区 ， 
ee 多 个 组 件 。 
这 里 的 无 符号 整数 读 取 位 于 body 和 footer 
A 
messageWithFooter.readableBytes() - footer.readableBytes() - 1); 


Automatic Capacity Extension 自动 容量 扩展 


许多 协议 定义 可 变 长 度 的 消息 ， 这 意味 着 没有 办 法 确定 消息 的 长 度 ， 直 到 你 的 息 。 或 
者 ， 在 计算 长 度 的 精确 值 时 ， 带 来 了 困难 和 不 便 。 oe 你 经 常 估计 
得 到 的 字符 串 的 长 度 ， 让 StringBuffer 扩大 了 其 本 身 的 需求 。 


// 一 种 新 的 动态 缓冲 区 被 创建 。 在 内 部 ， 实 际 缓冲 区 是 被 “ 懒 " 创 建 ， 从 而 避免 潜在 的 浪费 内 存 空间 。 
ByteBuf b = Unpooled.buffer(4); 


// 当 第 一 个 执行 写 尝试 ， 内 部 指定 初始 容量 4 的 缓冲 区 被 创建 
b.writeByte('1'); 


b.writeByte('2'); 
b.writeByte('3'); 
b.writeByte('4'); 


// 当 写 入 的 字 节 数 超过 初始 容量 4 时 ， 
// 内 部 缓冲 区 自动 分 配 具 有 较 大 的 容量 
b.writeByte('5'); 


Better Performance 更 好 的 性 能 


最 频繁 使 用 的 缓冲 区 ByteBuf 的 实现 是 一 个 非常 薄 的 字 节 数组 包装 器 ( 比如， 一 个 字 节 ) 。 
与 ByteBuffer 不 同 ， 它 没有 复杂 的 边界 和 索引 检查 补偿 ， 因 此 对 于 JVM 优化 缓冲 区 的 访问 更 
加 简单 。 更 多 复杂 的 缓冲 区 实现 是 用 于 拆 分 或 者 组 合 缓存 ， 并 且 比 ByteBuffer 拥有 更 好 的 性 
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Universal Asynchronous I/O API 统一 的 弄 
步 VO API 


传统 的 Java lI/O API 在 应 对 不 同 的 传输 协议 时 需要 使 用 不 同 的 类 型 和 方法 。 例 如 : 
java.net.Socket 和 java.net.DatagramSocket 它们 并 不 具有 相同 的 超 类 型 ， 因 此 ， 这 就 需要 使 
用 不 同 的 调用 方式 执行 socket 操作 。 


这 种 模式 上 的 不 匹配 使 得 在 更 换 一 个 网 络 应 用 的 传输 协议 时 变 得 繁杂 和 困难 。 由 于 〈Java 1/O 
API) 缺乏 协议 间 的 移植 性 ， 当 你 试图 在 不 修改 网 络 传输 层 的 前 提 下 增加 多 种 协议 的 支持 ， 这 
时 便 会 产生 问题 。 并 且 理 论 上 讲 ， 多 种 应 用 层 协 议 可 运行 在 多 种 传输 层 协议 之 上 例如 
TCP/IP,UDP/IP,SCTP 和 串口 通信 。 


让 这 种 情况 变 得 更 糟 的 是 ，Java 新 的 JO (NIO) API 与 原 有 的 阻塞 式 的 MO (OIO) API 并 不 
兼容 ，NIO.2(AIO) 也 是 如 此 。 由 于 所 有 的 API 无 论 是 在 其 设计 上 还 是 性 能 上 的 特性 都 与 彼此 不 
同 ， 在 进入 开发 阶段 ， 你 常常 会 被 迫 的 选择 一 种 你 需要 的 API 。 


例如 ， 在 用 户 数 较 小 的 时 候 你 可 能 会 选择 使 用 传统 的 OIO(Old WO) API， 毕 竞 与 NIO 相 比 使 
用 OIO 将 更 加 容易 一 些 。 然 而 ， 当 你 的 业务 呈 指 数 增长 并 且 服 务 器 需要 同时 处 理 成 千 上 万 的 
客户 连接 时 你 便 会 遇 到 问题 。 这 种 情况 下 你 可 能 会 尝试 使 用 NIO， 但 是 复杂 的 NIO Selector 
编程 接口 又 会 耗费 你 大 量 时间 并 最 终 会 阻碍 你 的 快速 开发 。 


Netty 有 一 个 叫做 Channel 的 统一 的 异步 |/O 编程 接口 ， 这 个 编程 接口 抽象 了 所 有 点 对 点 的 通 
信 操 作 。 也 就 是 说 ， 如 果 你 的 应 用 是 基于 Netty 的 茶 一 种 传输 实现 ， 那 么 同样 的 ， 你 的 应 用 也 
可 以 运行 在 Netty 的 另 一 种 传输 实现 上 。Netty 提供 了 几 种 拥有 相同 编程 接口 的 基本 传输 实 
现 : 


。 基于 NIO 的 TCP/IP 传输 ( 见 io.netty.channel.nio)， 
。 基于 OIO 的 TCP/IP 传输 ( 见 io.netty.channel.oio)， 
。 基于 OIO 的 UDP/IP 传输 , 和 

。 本 地 传输 ( 见 io.netty.channel.local). 


切换 不 同 的 传输 实现 通常 只 需 对 代码 进行 几 行 的 修改 调整 ， 例 如 选择 一 个 不 同 的 
ChannelFactory 实现 。 
此 外 ， 你 甚至 可 以 利用 新 的 传输 实现 没有 写 入 的 优势 ， 只 需 替 换 一 些 构造 器 的 调用 方法 即 


可 ， 例 如 串口 通信 。 而 且 由 于 核心 API 具有 高 度 的 可 扩展 性 ， 你 还 可 以 完成 自己 的 传输 实 
现 。 


Event Model based on the Interceptor 
Chain Pattern 基于 拦截 链 模式 的 事件 模型 


一 个 定义 良好 并 具有 扩展 能 力 的 事件 模型 是 事件 驱动 开发 的 必要 条 件 。Netty 具有 定义 良好 的 
IO 事件 模型 。 由 于 严格 的 层次 结构 区 分 了 不 同 的 事件 类 型 ， 因 此 Netty 也 允许 你 在 不 破坏 现 
有 代码 的 情况 下 实现 自己 的 事件 类 型 。 这 是 与 其 他 框架 相 比 另 一 个 不 同 的 地 方 。 很 多 NIO 杠 
架 没有 或 者 仅 有 有 限 的 事件 模型 概念 ; 在 你 试图 添加 一 个 新 的 事件 类 型 的 时 候 常 常 需要 修改 

已 有 的 代码 ， 或 者 根本 就 不 允许 你 进行 这 种 扩展 。 


在 一 个 ChannelPipeline 内 部 一 个 ChannelEvent 被 一 组 ChannelHandler 处 理 。 这 个 管道 是 
Intercepting Filter (拦截 过 滤器 ) 模 式 的 一 种 高 级 形式 的 实现 ， 因 此 对 于 一 个 事件 如 何 被 处 理 以 
及 管道 内 部 处 理 器 间 的 交互 过 程 » 你 都 将 拥有 绝对 的 控制 力 例如 你 可 以 定义 一 个 从 
socket 读 取 到 数据 后 的 操作 : 


public class MyReadHandler implements SimpleChannelHandler { 
public void messageReceived(ChannelHandlerContext ctx, MessageEvent evt) { 
Object message = evt.getMessage(); 
// Do something with the received message. 


// And forward the event to the next handler. 
ctx.sendUpstream(evt); 


同时 你 也 可 以 定义 一 种 操作 响应 其 他 处 理 器 的 写 操作 请 求 : 


public class MyWriteHandler implements SimpleChannelHandler { 
public void writeRequested(ChannelHandlerContext ctx, MessageEvent evt) { 
Object message = evt.getMessage(); 
// Do something with the message to be written. 


// And forward the event to the next handler. 
ctx.sendDownstream(evt); 


有 关 事 件 模 型 的 更 多 信息 ， 请 参考 API 文档 ChannelEvent 和 ChannelPipeline 部 分 。 


Event Model based on the Interceptor Chain Pattern 基于 拦截 链 模式 的 事件 模型 
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Advanced de for More Rapid 
Development 适用 快速 开发 的 高 级 组 件 


上 述 所 提 及 的 核心 组 件 已 经 足够 实现 各 种 类 型 的 网 络 应 用 ， 除 此 之 外 ，Netty 也 提供 了 一 系列 
的 高 级 组 件 来 加 速 你 的 开发 过 程 。 


Codec 框架 


就 像 "使 用 POJO 代 蔡 ChannelBuffer 一 节 所 展示 的 那样 ， 从 业务 逻辑 代码 中 分 离 协议 处 理 部 分 
总 是 一 个 很 不 错 的 想法 。 然 而 如 果 一 切 从 零 开 始 便 会 遭遇 到 实现 上 的 复杂 性 。 你 不 得 不 处 理 
分 段 的 消息 。 一 些 协议 是 多 层 的 (例如 构建 在 其 他 低层 协议 之 上 的 协议 ) 。 一 些 协议 过 于 复 
杂 以 致 难以 在 一 台独 立 状态 机 上 实现 。 


因此 ， 一 个 好 的 网 络 应 用 框架 应 该 提供 一 种 可 扩展 ， 可 重用 ， 可 单元 测试 并 且 是 多 层 的 
codec 框架 ， 为 用 户 提供 易 维 护 的 codec 代码 。 


Netty 提供 了 一 组 构建 在 其 核心 模块 之 上 的 codec 实现 ， 这 些 简 单 的 或 者 高 级 的 codec 实现 
帮 你 解决 了 大 部 分 在 你 进行 协议 处 理 开 发 过 程 会 遇 到 的 问题 ， 无 论 这 些 协 议 是 简单 的 还 是 复 
杂 的 ， 二 进 制 的 或 是 简单 文本 的 。 


SSL /TLS 支持 


不 同 于 传统 阻塞 式 的 |/O 实现 ， 在 NIO 模式 下 支持 SSL 功能 是 一 个 艰难 的 工作 。 你 不 能 只 是 
简单 的 包装 一 下 流 数据 并 进行 加 密 或 解密 工作 ， 你 不 得 不 借助 于 javax.net.ssl.SSLEngine ， 
SSLEngine 是 一 个 有 状态 的 实现 ， 其 复杂 性 不 亚 于 SSL 自身 。 你 必须 管理 所 有 可 能 的 状态 ， 
例如 密码 套件 ， 密 铀 协商 (或 重新 协商 ) ， 证 书 交换 以 及 认证 等 。 此 外 ， 与 通常 期 望 情况 相 
反 的 是 SSLEngine 其 至 不 是 一 个 绝对 的 线程 安全 实现 。 


在 Netty 内 部 ，SslHandler 封装 了 所 有 艰难 的 细节 以 及 使 用 SSLEngine 可 能 带 来 的 陷阱 。 你 
所 做 的 仅 是 配置 并 将 该 SslHandler ea 你 的 ChannelPipeline 中 。 同 样 Netty 也 允许 你 实 
现 像 StartTIS 那样 所 拥有 的 高 级 特性 ， 这 很 容易 。 


HTTP 实现 


HTTP 无 疑 是 互联 网 上 最 受 欢 迎 的 协议 ， 并 且 已 经 有 了 一 些 例如 Servlet 容器 这 样 的 HTTP 实 
现 。 因 此 ， 为 什么 Netty 还 要 在 其 核心 模块 之 上 构建 一 套 HTTP 实现 ? 


与 现 有 的 HTTP 实现 相 比 Netty 的 HTTP 实现 是 相当 与 众 不 同 的 。 在 HTTP 消息 的 低层 交互 
过 程 中 你 将 拥有 绝对 的 控制 力 。 这 是 因为 Netty 的 HTTP 实现 只 是 一 些 HTTP codec 和 HTTP 
消息 类 的 简单 组 合 ， 这 里 不 存在 任何 限制 一 例如 那 种 被 迫 选 择 的 线程 模型 。 你 可 以 随心 所 
欲 的 编写 那 种 可 以 完全 按照 你 期 望 的 工作 方式 工作 的 客户 端 或 服务 器 端 代码 。 这 包括 线程 模 
型 ， 连 接生 命 期 ， 快 编码 ， 以 及 所 有 HTTP 协议 允许 你 做 的 ， 所 有 的 一 切 ， 你 都 将 拥有 绝对 
的 控制 力 。 


由 于 这 种 高 度 可 定制 化 的 特性 ， 你 可 以 开发 一 个 非常 高 效 的 HTTP 服 务 器 ， 例 如 : 


e。 要 求 持久 化 链接 以 及 服务 器 端 推送 技术 的 聊天 服务 (如 ，Comet ) 

。 需要 保持 链接 直至 整个 文件 下 载 完成 的 媒体 流 服务 (如 ，2 小 时 长 的 电影 ) 
e 需要 上 传 大 文件 并 且 没 有 内 存 压力 的 文件 服务 《如 ， 上 传 1GB 文 件 的 请 求 ) 
e。 支持 大 规模 混合 客户 端 应 用 用 于 连接 以 万 计 的 第 三 方 异 步 Web 服务 。 


WebSockets 实现 

WebSockets 允许 双向 ， 全 双 工 通信 信道 ， 在 TCP socket 中 。 它 被 设计 为 允许 一 个 Web 浏 
览 器 和 Web 服务 器 之 间 通 过 数据 流 交互 。 

WebSocket 协议 已 经 被 IETF 列 为 RFC 6455 规 范 。 


Netty 实现 了 RFC 6455 和 一 些 老 版 本 的 规范 。 请 参阅 io.netty.handler.codec.http.websocketx 
包 和 相关 的 例子 。 


Google Protocol Buffer 整合 


Google Protocol Buffers 是 快速 实现 一 个 高 效 的 二 进 制 协议 的 理想 方案 。 通 过 使 用 
ProtobufEncoder 和 ProtobufDecoder， 你 可 以 把 Google Protocol Buffers 编译 器 (protoc) 生 
成 的 消息 类 放 入 到 Netty 的 codec 实现 中 。 请 参考 “LocalTime” 实 例 ， 这 个 例子 也 同时 显示 出 
开发 一 个 由 简单 协议 定义 的 客户 及 服务 端 是 多 么 的 容易 。 


译 者 注 : 翻译 版 本 的 项 目 源码 见 https:/github.com/waylau/netty-4-user-guide-demos 


Summary 总 结 


在 这 一 章节 ， 我 们 从 功能 特性 的 角度 回顾 了 Netty 的 整体 架构 。Netty 有 一 个 简单 却 不 失 强 大 
的 架构 。 这 个 架构 由 三 部 分 组 成 缓冲 (buffer) ， 通 道 (channel) ， 事 件 模型 (event 
model) 一 一 所 有 的 高 级 特性 都 构建 在 这 三 个 核心 组 件 之 上 。 一 旦 你 理解 了 它们 之 间 的 工作 原 
理 ， 你 便 不 难 理解 在 本 章 简要 提 及 的 更 多 高 级 特性 。 





你 可 能 对 Netty 的 整体 架构 以 及 每 一 部 分 的 工作 原理 仍旧 存 有 和 疑问。 如果 是 这 样 ， 最 好 的 方式 
是 告诉 我 们 应 该 如 何 改进 这 份 指 南 。 


译 者 注 : 对 本 翻译 有 任何 疑问 ， 在 https:/github.com/Wwaylau/netty-4-user-guide/issues 提 问 


